dev-support/design-docs/HBASE-24289-Heterogeneous Storage for Date Tiered Compaction.md

   1 <!--
   2  Licensed to the Apache Software Foundation (ASF) under one
   3  or more contributor license agreements.  See the NOTICE file
   4  distributed with this work for additional information
   5  regarding copyright ownership.  The ASF licenses this file
   6  to you under the Apache License, Version 2.0 (the
   7  "License"); you may not use this file except in compliance
   8  with the License.  You may obtain a copy of the License at
   9
  10      http://www.apache.org/licenses/LICENSE-2.0
  11
  12  Unless required by applicable law or agreed to in writing, software
  13  distributed under the License is distributed on an "AS IS" BASIS,
  14  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  15  See the License for the specific language governing permissions and
  16  limitations under the License.
  17 -->
  18
  19 # Heterogeneous Storage for Date Tiered Compaction
  20
  21 ## Objective
  22
  23 Support DateTiredCompaction([HBASE-15181](https://issues.apache.org/jira/browse/HBASE-15181))
  24  for cold and hot data separation, support different storage policies for different time periods
  25  of data to get better performance, for example, we can configure the data of last 1 month in SSD,
  26  and 1 month ago data was in HDD.
  27
  28 + Date Tiered Compaction (DTCP) is based on date tiering (date-aware), we hope to support
  29   the separation of cold and hot data, heterogeneous storage. Set different storage
  30   policies (in HDFS) for data in different time windows.
  31 + DTCP designs different windows, and we can classify the windows according to
  32   the timestamps of the windows. For example: HOT window, WARM window, COLD window.
  33 + DTCP divides storefiles into different windows, and performs minor Compaction within
  34   a time window. The storefile generated by Compaction will use the storage strategy of
  35   this window. For example, if a window is a HOT window, the storefile generated by compaction
  36   can be stored on the SSD. There are already WAL and the entire CF support storage policy
  37   (HBASE-12848, HBASE-14061), our goal is to achieve cold and hot separation in one CF or
  38   a region, using different storage policies.
  39
  40 ## Definition of hot and cold data
  41
  42 Usually the data of the last 3 days can be defined as `HOT data`, hot age = 3 days.
  43  If the written timestamp of the data(Cell) is > (timestamp now - hot age), we think the data is hot data.
  44  Warm age can be defined in the same way. Only one type of data is allowed.
  45  If data timestamp < (now - warm age), we consider it is COLD.
  46  ```
  47   if timestamp >= (now - hot age) , HOT data
  48   else if timestamp >= (now - warm age), WARM data
  49   else COLD data
  50 ```
  51
  52 ## Time window
  53 When given a time now, it is the time when the compaction occurs. Each window and the size of
  54  the window are automatically calculated by DTCP, and the window boundary is rounded according
  55  to the base size.
  56 Assuming that the base window size is 1 hour, and each tier has 3 windows, the current time is
  57  between 12:00 and 13:00. We have defined three types of winow (`HOT, WARM, COLD`). The type of
  58  winodw is determined by the timestamp at the beginning of the window and the timestamp now.
  59 As shown in the figure 1 below, the type of each window can be determined by the age range
  60  (hot / warm / cold) where (now - window.startTimestamp) falls. Cold age can not need to be set,
  61  the default Long.MAX, meaning that the window with a very early time stamp belongs to the
  62  cold window.
  63 ![figure 1](https://raw.githubusercontent.com/pengmq1/images/master/F1-HDTCP.png "figure 1")
  64
  65 ## Example configuration
  66
  67 | Configuration Key | value | Note |
  68 |:---|:---:|:---|
  69 |hbase.hstore.compaction.date.tiered.storage.policy.enable|true|if or not use storage policy for window. Default is false|
  70 |hbase.hstore.compaction.date.tiered.hot.window.age.millis|3600000|hot data age
  71 |hbase.hstore.compaction.date.tiered.hot.window.storage.policy|ALL_SSD|hot data storage policy, Corresponding HDFS storage policy
  72 |hbase.hstore.compaction.date.tiered.warm.window.age.millis|20600000||
  73 |hbase.hstore.compaction.date.tiered.warm.window.storage.policy|ONE_SSD||
  74 |hbase.hstore.compaction.date.tiered.cold.window.storage.policy|HOT||
  75
  76 The original date tiered compaction related configuration has the same meaning and maintains
  77  compatibility.
  78 If `hbase.hstore.compaction.date.tiered.storage.policy.enable = false`. DTCP still follows the
  79  original logic and has not changed.
  80
  81 ## Storage strategy
  82 HDFS provides the following storage policies, you can refer to
  83  https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/ArchivalStorage.html
  84
  85 |Policy ID | Policy Name | Block Placement (3  replicas)|
  86 |:---|:---|:---|
  87 |15|Lasy_Persist|RAM_DISK: 1, DISK: 2|
  88 |12|All_SSD|SSD: 3|
  89 |10|One_SSD|SSD: 1, DISK: 2|
  90 |7|Hot (default)|DISK: 3|
  91 |5|Warm|DISK: 1, ARCHIVE: 2|
  92 |2|Cold|ARCHIVE: 3|
  93
  94 Date Tiered Compaction (DTCP) supports the output of multiple storefiles. We hope that these
  95  storefiles can be set with different storage policies (in HDFS).
  96  Therefore, through DateTieredMultiFileWriter to generate different StoreFileWriters with
  97   storage policy to achieve the purpose.
  98
  99 ## Why use different child tmp dir
 100 Before StoreFileWriter writes a storefile, we can create different dirs in the tmp directory
 101  of the region and set the corresponding storage policy for these dirs. This way
 102  StoreFileWriter can write files to different dirs.
 103
 104 Since **HDFS** does not support the create file with the storage policy parameter
 105  (See https://issues.apache.org/jira/browse/HDFS-13209 and now not support on hadoop 2.x),
 106  and HDFS cannot set a storage policy for a file / dir path that does not yet exist.
 107  When the compaction ends, the storefile path must exist at this time, and I set the
 108  storage policy to Storefile.
 109
 110 But, in HDFS, when the file is written first, and then the storage policy is set.
 111  The actual storage location of the data does not match the storage policy. For example,
 112  write three copies of a file (1 block) in the HDD, then set storage policy is ALL_SSD,
 113  but the data block will not be moved to the SSD immediately.
 114  “HDFS wont move the file content across different block volumes on rename”. Data movement
 115  requires the HDFS mover tool, or use HDFS SPS
 116  (for details, see https://issues.apache.org/jira/browse/HDFS-10285), so in order to
 117  avoid moving data blocks at the HDFS level, we can set the file parent directory to
 118  the storage policy we need before writing data. The new file automatically inherits the
 119  storage policy of the parent directory, and is written according to the correct disk
 120  type when writing. So as to avoid later data movement.
 121
 122 Over time, the original HOT data will become WARM / COLD and no longer belong to the
 123  HOT window. When the compaction occurs again, the data will be automatically downgraded,
 124  such as from SSD to HDD. The compaction mechanism will generate a new file (write into HDD)
 125  and delete it Old file (SSD).